Import velkeho mnozstvi dat do FB

Otázka od: Dalibor

5. 11. 2004 10:42

Ahoj, casto importuju do DB Firebirdu velke mnostvi zaznamu. Radove stovky
tisic.
V soucasne dobe na to pouzivam dve FibQuery.
Jedna, ktera zjistuje jestli dany zaznam existuje a druha Query, ktera je
parametricka a udaje uklada do databaze.

Jenze to trva hodne dlouho.

Nemate nekdo nejakej tip na jiny, rychlejsi zpusob importu?
Nejdyl asi trva zjistovani, jestli dany radek existuje. Testuje se sloupec
KLIC a mam na nem nastaveny index.

Dekuji za radu.

Dalibor

FB 1.5, Delphi 7


Odpovedá: delphin@post.cz

5. 11. 2004 10:46

> Ahoj, casto importuju do DB Firebirdu velke mnostvi zaznamu. Radove stovky
> tisic.
> V soucasne dobe na to pouzivam dve FibQuery.
> Jedna, ktera zjistuje jestli dany zaznam existuje a druha Query, ktera je
> parametricka a udaje uklada do databaze.

Jedna z moznosti je vsechny data pro import dat do pomocne tabulky a pote je
najednou ve stored procedure vlozit tam, kam patri.


Odpovedá: Pavel Cisar

5. 11. 2004 11:56

Haj hou!

On 5 Nov 2004 at 10:41, Dalibor wrote:

> Ahoj, casto importuju do DB Firebirdu velke mnostvi zaznamu. Radove stovky
> tisic.
> V soucasne dobe na to pouzivam dve FibQuery.
> Jedna, ktera zjistuje jestli dany zaznam existuje a druha Query, ktera je
> parametricka a udaje uklada do databaze.
>
> Jenze to trva hodne dlouho.
>
> Nemate nekdo nejakej tip na jiny, rychlejsi zpusob importu?
> Nejdyl asi trva zjistovani, jestli dany radek existuje. Testuje se sloupec
> KLIC a mam na nem nastaveny index.

Pokud je KLIC jedinecny, pak staci pouze vkladat. Pokud zaznam
existuje, vyhuci vlozeni daneho radku na chybu, ktera se bude proste
ignorovat.

S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase


Odpovedá: Slavomir Skopalik

5. 11. 2004 13:32

Tipy:
1. Zjisti kde je uzke hrdlo (CPU, nebo DISK)?
2. Zvaz moznost deaktivace trigru a indexu
3. Pokud se ti vyskytuje velke mnozstvi duplicit, zvaz toto resit
  na klientovi (nacist vsechny zaznamy do pameti serazene
  a pomoci puleni intervalu vyhledavat}, ale jen v pripade, ze
  to nebude vytvaret pametove problemy na klientovi (klic je vetsinou
  32 bit integer, dnes neni problem alokovat 100MB RAM -> 25 mil.
zaznamu)
  a vyrazovani zaznamu provadet jiz na klientovy (compilovany kod).
4. Je pomalost opravdu na zavadu ? Mnohdy programatori
  resi nepodstatne veci.
5. Je nutno ty data skutecne importovat ?

 Slavek

> Ahoj, casto importuju do DB Firebirdu velke mnostvi zaznamu.
> Radove stovky tisic. V soucasne dobe na to pouzivam dve
> FibQuery. Jedna, ktera zjistuje jestli dany zaznam existuje a
> druha Query, ktera je parametricka a udaje uklada do databaze.
>
> Jenze to trva hodne dlouho.
>
> Nemate nekdo nejakej tip na jiny, rychlejsi zpusob importu?
> Nejdyl asi trva zjistovani, jestli dany radek existuje.
> Testuje se sloupec KLIC a mam na nem nastaveny index.
>
> Dekuji za radu.


Odpovedá: Dalibor

5. 11. 2004 13:50

A nebude to spusobovat nejaky problem primo na Firebird serveru?
Treba nejaky "Memory leak", zahlceni serveru, atd?
Kdyz si treba vemu 600000 exceptionu diky duplicite zaznamu.

> Pokud je KLIC jedinecny, pak staci pouze vkladat. Pokud zaznam
> existuje, vyhuci vlozeni daneho radku na chybu, ktera se bude proste
> ignorovat.
>
> S pozdravem
> Pavel Cisar ( ICQ: 89017288)


Odpovedá: Richard Kejval

5. 11. 2004 15:14

----- Original Message -----
From: "Dalibor" <dalibor@torola.cz>


> Ahoj, casto importuju do DB Firebirdu velke mnostvi zaznamu. Radove stovky
> tisic.
> V soucasne dobe na to pouzivam dve FibQuery.
> Jedna, ktera zjistuje jestli dany zaznam existuje a druha Query, ktera je
> parametricka a udaje uklada do databaze.
>
> Jenze to trva hodne dlouho.

Mame udalanou datovou pumpu, ktera presouva data z 1 nebo vice zdrojovych
fdb
do 1 cilove fdb. Data se pohybuji v 10 mil. zaznamu.

Delame to 2 zpusoby:

1. V kazdem pripade napumpuji data bez ohledu na vazby: (rychlejsi varianta)
  - obnova fdb ze zalohy + Deactivate Indices = true (jediny zpusob jak
vypnout
     primarni a cizi klice)
  - programove vypnuti vsech triggeru
  - velmi rychly prenos dat
  - programove zapnuti triggeru
  - postupne programove zapnuti indexu a zapsani do logu tech ktere z
nejakych
    vazebnich duvodu nejdou zapnout
  - pak se musi pripadne rucne opravit data a indexy pozapinat => cena za
     rychlost

2. Ponechani zapnuti indexu: (pomalejsi varianta)
  - pumpovani dat a vyhazovani do logu SQL prikazu, ktere hodi pri zapisu
chybu

Zvazeni, ktery postup se pouzije uz zavisi na konkretnim posouzeni situace.
Variantu 1 vetsinou pouzivame, kdyz prechazime na jinou strukturu databaze

V kazdem pripade pro nacitani dat pouzivame TIBQuery, pozor s parametrem
UniDirectional=true, jinak se vsechny zaznamy budou nacitat do pameti, coz u
velkych tabulek, znamenalo az pad systemu. A na zapis uz pouzivame pouze
TIBSQL

Asi to nebude presne to co potrebujes, ale treba Ti to pomuze.

S pozdravem
ing. Richard Kejval
mobil: 602477679
http://www.icsoftware.cz


Odpovedá: Pavel Cisar

5. 11. 2004 16:06

Haj hou!

On 5 Nov 2004 at 13:50, Dalibor wrote:

> A nebude to spusobovat nejaky problem primo na Firebird serveru?
> Treba nejaky "Memory leak", zahlceni serveru, atd?
> Kdyz si treba vemu 600000 exceptionu diky duplicite zaznamu.

Ne, nebude. Pokud by se skutecne ukazal nejaky memory leak, pak je
traba ho nahlasit a my to opravime.

S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase


Odpovedá: Ludek ZITA

6. 11. 2004 0:15

> > Pokud je KLIC jedinecny, pak staci pouze vkladat. Pokud zaznam
> > existuje, vyhuci vlozeni daneho radku na chybu, ktera se
> bude proste
> > ignorovat.
>
> A nebude to spusobovat nejaky problem primo na Firebird
> serveru? Treba nejaky "Memory leak", zahlceni serveru, atd?
> Kdyz si treba vemu 600000 exceptionu diky duplicite zaznamu.

Ahoj,
Nechci delat chytryho, ale jedna se jen o doplneni o nove zaznamy ?
Je mi divne proc vstupni soubor obsahuje takove mnozstvi nepotrebnych
dat a jestli by nebylo v tom pripade lepsi nejprve z FB vyexportovat
pouze KLIC, podle tohoto klice na klientovi odstranit nepotrebne radky,
a pak teprve ten zbytek cpat do FB.
Vyhledavat az pri "akci" ze tohle zrovna nechci je divne a zasadni chybu
bych videl prave v existenci tech nadbytecnych vet ve vstupnim souboru.

Ludek